1. Field of the Invention
The invention relates generally to accessing storage subsystems, and, more particularly, to multiple-protocol-accessible object-based-storage-device storage systems.
2. Description of the Related Art
In recent years, Fibre Channel (FC) connectivity for storage systems and Fibre Channel-based storage area networks (FC-SANs) have become more common in the storage industry. Fibre Channel has been adopted as an American National Standards Institute (ANSI) standard, which was originally intended for high-speed SANs connecting servers, disk arrays, and backup devices. The first Fibre Channel protocol was approved by the ANSI standards committee in 1994, running at 100 Mb/s. Under more recent innovations, the speeds of FC-SANs have increased to 10 Gb/s, and higher. Many network architectures are possible with Fibre Channel, with one popular arrangement including a number of devices attached to one or two (for redundancy) central Fibre Channel switches, creating a reliable infrastructure that allows hosts and servers to share disk storage arrays, tape libraries, or the like.
Current storage subsystems such as Hitachi's TagmaStore™ Universal Storage Platform include connection capabilities for ANSI FCP-3 (Fibre Channel Protocol 3). (See, e.g., The International Committee for Information Technology Standards (INCITS) “T10, Project 1560-D, Revision 3g”, t10.org/ftp/t10/drafts/fcp3/fcp3r03g.pdf, hereinafter, “ANSI FCP-3”.) The TagmaStore™ Universal Storage Platform is able to store and protect data using RAID technology, and provides for storage of data via various other protocols as well, such as CIFS, NFS, FC-SCSI, and FICON® (a proprietary Fibre Connectivity protocol developed by IBM Corporation for use with mainframe computers). These various data access protocols require different accommodations to function with a storage system. For example, the FC-SCSI protocol uses an FBA (fixed block architecture) format for storage, while the FICON® protocol uses a CKD (count key data) format, which is commonly used for communication between storage systems and mainframes. U.S. Pat. No. 6,499,056, to Kitamura et al., the disclosure of which is incorporated herein by reference, discloses a storage system that includes both an FBA interface and a CKD interface.
In the FBA format used in the FC-SCSI protocol, the data is stored in a specified region known as a “block”. Each of the blocks typically has a fixed length, such as 512 bytes. A logical block address (LBA) is assigned to each block, and the LBA is used when accessing the data in a block. Contrarily, in the CKD format, such as is used in the FICON® protocol, a cylinder number (CC), a head number (HH) and a record number (R) are assigned to an associated record to enable access. Thus, the minimum amount of data that may be accessed using the CKD format is an entire record.
Further, multiple external storage systems connected to a TagmaStore™ Universal Storage Platform are presented to a user as if the multiple storage systems were merely additional internal storage in a common storage pool, managed by the Universal Storage Platform's software tools. This external storage can be grouped into classes based on attributes of performance, availability, recoverability, and cost, but is functionally equivalent to internal storage as far as software for data migration and replication or host-based software is concerned.
Also, in recent years, SCSI Object-Based Storage Device Commands have become standardized by ANSI and INCITS. The SCSI (Small Computer Systems Interface) command set for use with Object-Based Storage Devices (OSDs) provides for efficient operation of input/output logical units that manage the allocation, placement, and accessing of variable-sized data-storage “objects”. Current OSD architecture treats storage as neither traditional blocks nor files, but as objects that are comprised of data and attributes of the data. For example, an object might be a part of a file, many files, or parts of many files, along with attribute information regarding the data that makes up the object. The OSD is typically aware of the content of the object, and is able to handle the lower-level details of device management, such as block allocation. (See, e.g., American National Standard Institute standard “ANSI INCITS 400-2004” (ansi.org) and “SCSI Object-Based Storage Device Commands-2 (OSD-2)” (t10.org/ftp/t10/drafts/osd2/osd2r00.pdf, hereinafter “OSD-2”.) According to the OSD specifications, OSDs provide an access method for data specifying USER_OBJECT_ID based on the SCSI specification, which may be referred to as the SCSI-OSD format. In the following, “OSD” refers to SCSI-OSD.
In general, to access several storage or data access protocols on a SCSI-OSD-capable storage subsystem (i.e., which provides one or more object-based volumes), it is necessary to provide a separate storage subsystem for each data access protocol. For example, when a host requires access to a SCSI-OSD volume, the storage subsystem prepares a SCSI-OSD storage subsystem for the host. When a host requires access to an FC-SCSI-based volume which provides logical block addresses through Fibre Channel on a SCSI-OSD storage subsystem, there is no capability for the storage subsystem to provide an FC-SCSI-based (LBA) volume, and it becomes necessary to prepare a new storage subsystem to store FC-SCSI formatted data. This is time consuming and inefficient. Further, conventional storage systems and networks provide no method to share SCSI-OSD protocol and FC-SCSI protocol in a single port.